home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1995 October
/
EnigmA AMIGA RUN 01 (1995)(G.R. Edizioni)(IT)[!][issue 1995-10][Aminet 7].iso
/
Aminet
/
dev
/
asm
/
Asm_Course2.lha
/
Teil30.TXT
< prev
next >
Wrap
Text File
|
1992-09-02
|
10KB
|
190 lines
A S S E M B L E R - K U R S (c) Jeff Kandle 1991
30.Teil...
Puh, das war aber jetzt eine lange Pause mit diesem Kurs, aber ich hatte
Facharbeiterpruefung, und da muss man ja ein bisschen ueben, oder?
Da ich mir denke das viele schon sehr weit sind mit Assemblern, da koennte
wir mal besprechen wie man ein Intro schreibt. Nicht vom Programm her, das
muesstet ihr schon koennen sondern vom drumherum. Die vorbereitungen und
so.
Als, erstes muss ich sagen das ich mich nicht hinsetzen kann und sagen,
`Jetzt schreibe ich ein Intro`. Ich schreibe meine Intros immer dann wenn
ich irgendeinen guten Effekt programmiert habe, der gut in ein Intro passen
koennte. Dann setze ich mich hin, hoere Musik, und ueberlege mir das drum
herum. Was noch passieren muesste. Der Nachteil liegt darin, das der Effekt
den ich als Grundlage nehme, immer der Hauptteil des Intro`s bleibt, und
man den rest drumherum programmiert. Das ist natuerlich nicht die Optimale
loesung. Deshalb gehe ich so vor:
Sobald ich einen Introreifen Effekt programmiert habe, denke ich mir das
Intro aus, wo er gut reinpassen wuerde, und schreibe mir alles was reim
muss, und alles was noch reinpasst auf.
Muss-
Laufschrift
Kann-
Schwabbeln
Wasser
Sterne
Schwingendes Logo
Laufschrift ist finde ich ein muss fuer ein Intro. Da das was man mitteilen
will ja in nicht zu aufdringlicher form vorhanden sein muss, aber das Ziel
eines Intro ja der ist, zu sagen was sache ist und so. Demo`s, besonders
Teile von Megademos kommen manchmal ohne Laufschrift aus, da die Effekte
schon reichen um den Zuschauer bei dem teil zu lassen.
Dann sollte man sich gedanken machen wie das Demo ungefaehr aussehen soll.
Danach kann ich dann entscheiden was an zusatzeffekte noch eingbaut wird.
Es bringt absolut nichts wenn man in jedes Intro Sterne reinschmeisst, das
ist dann nichts besonderes mehr. Man muss sich ueberlegen was am besten
aussieht.
Nachdem man ungefaehr weiss wie das Intro aussehen soll, kann man sich
gedanken ueber aussehen und groesse der Laufschrift machen. Sie sollte sich
ins gesamtbild des Intro gut einfuegen.
Wenn man zum Beispiel auf dem Introscreen zwei effekte hat, die jeweils ein
drittel des Bildschirms belegen, dann kann man auch die Laufschrift ein
drittel des Screens grossmachen. Wenn man ein Logo das halb so gross ist
wie der Bildschirm ist, hat und einen Viertelscreen Effekt, dann sollte man
auch die Laufschrift nicht groesser machen.
Das ganze zeichnet man sich am Sinnvollste irgendwie auf. Dann beginnt die
Gliederung. Das heisst was ist am wichtigsten, und was muss von Zeitlichen
aufbau an erster und an zweiter Stelle kommen.
Hierbei ist wichtig wie der Screen auszusehen hat. Grundsaetzlich muss ja
die Musik zuerst gespielt werden. Da die Musik aber mit dem Prozessor und
Paula gemacht wird, koennen wir nebenbei noch dem Blitter etwas arbeit
geben. Also lassen wir sofern eine Blitter-Laufschrift vorhanden ist, und
diese in verschachtelten Plane auf den Bildschirm liegt, den Blitter
gleichzeitig mit der Musik, noch die Laufschrift eins oder zwei weiter
schieben. Wenn die Abspielroutine dann ans Intro zurueckgibt, dann ist der
Blitter schon fertig und kann andere aufgaben uebernehmen. Man muss
zwischen sichtbaren und unsichtbare Aktionen unterscheiden. Die sichtbare
sollte vor dem erscheinen auf dem bildschirm erledigt sein. Das heisst
nichts anderes, als das, das ich die Copperliste eines Wasser-Effekts der
bei Rasterzeile $80 beginnt, spaetestens bei $78 fertig haben sollte sonst
sieht es nicht so gut aus, der sich alte und neue Copperliste dann
vermischen. Weiter heisst es das ich sachen wie das Rotieren einer Farb.-
oder um beim Beispiel zu bleiben, einer Wassertabelle erledigen kann wann
ich will. Am sinnvollsten dann, wenn der Blitter gerade zu tun hat. Dabei
darf man naturlich nicht direkt nachdem Blitteraufruf in die Warteschleife
verzweigen, sondern muss erst das erledigen lassen was zu tun ist. Wenn
dann die Warteschleife noch noetig ist, also eine weitere Blitteraktion
gestartet wird, kann man sie einsetzen, falls keine Blitteraktion waehrend
dieses Bildschirmaufbaus stattfindet, kann man die Warte schleife ruhig
weglassen. Dieses Fehler findet man noch sehr oft in Demo`s und Intro`s
auch besserer Programmierer. Ich habe es auch eine Zeit gemacht, gebe ich
offen zu, aber das ist irgendwie Reflex, man Programmiert einen Blitter
aufruf, und wartet dann bis er fertig wird. Naja, beachtet das, und es wird
kuerzer...Zawr nur 12 Bytes, aber das ist ja auch schon was.
Ein Intelligenter ablauf eines Bildschirm aufbaues saehe dann ungefaehr so
aus.
Auf VHbreich warten.
Prozessor Blitter
Daten fuer Laufschrift-
Scroll an den Blitter ueber-
geben.
Blitter verschiebt Laufschrift
Musicroutine anspringen ()
() ()
Blitter daten fuer das rotieren
der groessten Tabelle geben.
Blitter rotiert groesste Tabelle
Prozessor wertet position der
Laufschrift aus, und errechnet die ()
Quellwerte des neuen Buchstabens aus.
Weiteren Laufschrift-Features werden ()
ausgewertet.
Dem Blitter das Kopieren des neue
Buchstabens aufgeben.
Blitter kopiert neuen Buchstaben
Andere aufgabe des Intros erledigen
(Stars, weitere tabellen, Mausabfrage) ()
Zurueck zum Anfang.
Natuerlich ist das nur ein kleines Intro ohne viel effekte, aber wenn man
sich diese Art und Weise an ein Intro macht, kann man sicher sein das man
die Zeit die man hat, und ebenfalls den Amiga, schon sehr gut ausgenutzt
hat. Wie ich schonmal erwaehnt habe, kann man auch den Copper sachen fuer
sich erledigen lassen. Den ersten Blitteraufruf fuer das verschieben der
Laufschrift ist dazu gut. Aber das ist nur sehr selten von noeten, und auch
nicht so Flexibel, da der Aufwand den das Umschreiben der Copperliste,
falls sich was an der Geschwindigkeit aendert, so gross ist, das kein
Geschwindigkeitsvorteil dabei rumkommt.
Sobald die zu erledigenden Aufgaben zahlreicher werden, sollte man sie
ausmessen, um die Ideale paarung zwischen Blitter und Prozessor gleichlauf
zu erreichen.
Mit ausmessen meine ich, die Zeit die eine Routine in Rasterzeilen braucht.
Um das rauszukriegen braucht man keine Taktzyklentabelle sondern laesst
einfach die Copperliste leer. Dann aendert man vor jeder Routine mit
Move.w Farbe,$Dff180, die Bildschirm farbe. Dann kann man mit Augenmass,
verschiedene Tatigkeiten kombinieren. Da die taetigkeiten die der Prozessor
ausfuehrt zwar komplizierter sind, aber nicht soviel Zeit brauchen, koennen
wir mehrere von ihnen in der Zeit einer Blitteraktion erledigen lassen.
Wenn man dann noch die Mischung zwischen sichtbarer und unsichtbarer Aktion
beherscht, dann kommt man auf sehr gute ergebnisse in der ausnutzung der
Zeit.
Natuerlich dauert es seine Zeit bis man das alles beachtet, aber es lohnt
sich wirklich. Den obwohl Intro/Demoprogrammierer ja angeblich schlechte
Programmierer sind, muessen auch von ihnen die Grundreglen des Programmierens
beachtet werden.
Desweiteren sollte man sein Intro/Demo gut strukturieren. Das Strukturieren
geht allerdings nicht nach einem ganz bestimmten Schema, sondern wie es
fuer euch am uerbsichtlichsten ist.
Ein Teil von euch wird meine Struktur uebernehmen, bis sie eine bessere
finden. Diese Strukturen unterscheiden sich nur durch Einzelheiten. Manche
schreiben alle Routinen direkt hintereinander, manche schreiben ein grosse
Aufruftabelle und lassen sie abarbeiten. Wie ihr das macht ist natuerlich
euch ueberlassen. Ihr solltet allerdings nicht jedesmal wenn ihr was neues
schreibt die Struktur wechseln, da sich das Gehirn ja auch daran gewoehnen
muss, wo es etwas zu suchen hat, und wo nicht.
Desweiteren ist es wichtig das ihr nach jedem Teilschritt das ganz wieder
abspeichert, und zwar jedesmal unter neuem Namen, denn nur so kann man sehr
genau festlegen was zum Fehler in der Routine fuehrte, und so braucht man
nicht zu grosse Stuecke neu zu programmieren. Da sich das aber schlecht auf
die uebersichtlichkeit der Disk auswirkt, koennt ihr sobald wieder zehn
Sources fertig sind, die alle in einen Order kopieren. So liegen sie euch
nicht im Weg und sind aber trotzdem da. Desweiteren solltet ihr der Zeit
wegen, Ueberlegen, ob ihr, falls ihr Grafiken oder Music einbindet, die
nach jedem Assemblieren wieder mit `y` reinzuholen. Meistens ist das
garnicht von noeten, da das Zeug ja nicht ueberschrieben wird. Das einzige
was eigentlich jedesmal eingebunden werden muss, ist die Musik. Aber da
kann man ja eingreifen in dem man sie nur abundzu in den Source einbaut, um
zu schauen wie es so laeuft. Desweiteren kann man ja auch die
Abspielroutine umschreiben, so das sie auf einen Feste Adresse zugreift,
anstatt einen PC-Relativen Wert zu holen.
Also aus Move.l Mt-Data(PC),A0
wird Lea $60000,A0
oder so aehnlich.
Falls aber Manipulationen am Bild stattfinden, solltet ihr wenigstens die
sachen aus dem Ram: holen lassen.
Desweiteren kann man bei sehr viel Grafik oder Musik, auch noch den vom
Seka zu reservierenden Bereich ins Fastmem legen, dann stoert und der
Source nicht mehr. Allerdings muesst ihr dann immer mit Org/Load arbeiten,
da die Sachen mit Blitter/Copper ja im Fastmem nicht laufen.
So, gibt es noch mehrere Tricks um sich Platz zu machen. Aber man muss sie
nicht oft anwenden bei der Intro/Demo Programmierung. Bei Spielen ist es da
schon etwas anderes, aber soweit sind wir ja noch nicht.
Den letzen Tip den ich euch noch geben kann, werden manche von euch schon
selber heraus gefunden haben. Setzt euch niemals mit schlechter Laune an
ein Programm...Denn wenn dann was falsch laeuft regt man sich nur unnoetig
auf, und dann klappt ueberhaupt nichts mehr. Dann sollte man eine Pause
miteinem netten Spiel einlegen, und dann sieht alles schon wieder viel
besser aus.
C.U.
Jeff Kandle